Evolved Packet System (EPS), is the evolved 3rd Generation Partnership Project (3GPP) Packet Switched Domain. EPS includes Evolved Packet Core (EPC), and Evolved Universal Terrestrial Radio Access Network (E-UTRAN). FIG. 1 shows an overview of the EPC architecture in a non-roaming context, which architecture includes a Packet Data Network (PDN) Gateway (PGW), a Serving Gateway (SGW), a Policy and Charging Rules Function (PCRF), a Mobility Management Entity (MME) and a wireless device also called a User Equipment (UE). The radio access, E-UTRAN, consists of one or more eNodeBs (eNB).
FIG. 2 shows the overall E-UTRAN architecture and includes eNBs, providing the E-UTRA user plane and control plane protocol terminations towards the UE. The user plane control terminations comprise Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC), Medium Access Control (MAC), and a Physical Layer (PHY). The control plane control terminations comprise Radio Resource Control (RRC) in addition to the listed user plane control terminations. The eNBs are interconnected with each other by means of an X2 interface. The eNBs are also connected by means of the S1 interface to the EPC, more specifically to the MME by means of the S1-MME interface and to the SGW by means of the S1-U interface.
The main parts of the EPC Control Plane and User Plane architectures are shown in FIG. 3 and FIG. 4, respectively.
Long Term Evolution (LTE) Overview
LTE uses Orthogonal Frequency Division Multiplexing (OFDM) in the Downlink (DL) and Direct Fourier Transform (DFT)-spread OFDM in the Uplink (UL). The basic LTE DL physical resource can thus be seen as a time-frequency grid as illustrated in FIG. 5, where each resource element corresponds to one OFDM subcarrier during one OFDM symbol interval.
In the time domain, LTE DL transmissions are organized into radio frames of 10 ms, each radio frame consisting of ten equally-sized subframes of length Tframe=1 ms (see FIG. 6). Furthermore, the resource allocation in LTE is typically described in terms of resource blocks (RB), where a RB corresponds to one slot (0.5 ms) in the time domain and 12 contiguous subcarriers in the frequency domain. A pair of two adjacent RBs in time direction (1.0 ms) is known as a RB pair. RBs are numbered in the frequency domain, starting with 0 from one end of the system bandwidth. The notion of virtual RBs (VRB) and physical RBs (PRB), has been introduced in LTE. The actual resource allocation to a UE is made in terms of VRB pairs. There are two types of resource allocations, localized and distributed. In the localized resource allocation, a VRB pair is directly mapped to a PRB pair, hence two consecutive and localized VRB are also placed as consecutive PRBs in the frequency domain. On the other hand, the distributed VRBs are not mapped to consecutive PRBs in the frequency domain; thereby providing frequency diversity for data channel transmitted using these distributed VRBs.
DL transmissions are dynamically scheduled, i.e., in each subframe the base station transmits control information about to which terminals data is transmitted and upon which RBs the data is transmitted in the current DL subframe. This control signaling is typically transmitted in the first 1, 2, 3 or 4 OFDM symbols in each subframe and the number n=1, 2, 3 or 4 is known as the Control Format Indicator (CFI). The DL subframe also contains Common Reference Symbols (CRS) which are known to the receiver and used for coherent demodulation of, e.g., the control information. A DL system with CFI=3 is illustrated in FIG. 7.
LTE Control and User Diane Architecture
Conventional control and user plane protocol architectures highlighting the radio interface on the eNB-side are shown in FIGS. 8a and 8b. The control and user plane consists of the following protocol layers and main functionality:                Radio Resource Control, RRC (control plane only)                    Broadcast of system information for both Non-access stratum (NAS) and Access stratum (AS)            Paging            RRC connection handling            Allocation of temporary identifiers for the UE            Configuration of signaling radio bearer(s) for RRC connection            Handling of radio bearers            QoS management functions            Security functions including key management            Mobility functions including:                            UE measurement reporting and control of the reporting                Handover                UE cell selection and reselection and control of cell selection and reselection                                    NAS direct message transfer to/from the UE                        Packet Data Convergence Protocol, PDCP                    There exists one PDCP entity for each radio bearer for the UE. PDCP is used for both control plane (RRC) and for user plane            Control plane main functions, including ciphering/deciphering and integrity protection            User Plane main functions, including ciphering/deciphering, header compression and decompression using Robust Header Compression (ROHC), and in-sequence delivery, duplicate detection and retransmission (mainly used during handover)                        Radio Link Control, RLC                    The RLC layer provides services for the PDCP layer and there exists one RLC entity for each radio bearer for the UE            Main functions for both control and user plane include segmentation or concatenation, retransmission handling (using Automatic Repeat Request (ARQ), duplicate detection and in-sequence delivery to higher layers.                        Medium Access Control, MAC                    The MAC provides services to the RLC layer in the form of logical channels, and performs mapping between these logical channels and transport channels            Main functions are: UL and DL scheduling, scheduling information reporting, hybrid-ARQ retransmissions and multiplexing/demultiplexing data across multiple component carriers for carrier aggregation                        Physical Layer, PHY                    The PHY provides services to the MAC layer in the form of transport channels and handles mapping of transport channels to physical channels.            Main functions for DL performed by the eNB (OFDM) are:                            Sending of DL reference signals                Detailed steps (from “top to down”): CRC insertion; code block segmentation and per-code-block CRC insertion; channel coding (Turbo coding); rate matching and physical-layer hybrid-ARQ processing; bit-level scrambling; data modulation (QPSK, 16QAM, or 64QAM); antenna mapping and multi-antenna processing; OFDM processing, including Inverse Fast Fourier Transform (IFFT), and Cyclic Prefix (CP) insertion resulting in time domain data sometimes referred to as IQ data or digitalized Radio Frequency (RF) data); digital-to-analog conversion; power amplifier; and sending to antenna.                                    Main functions for UL performed by the eNB (DFT-spread OFDM) are:                            Random access support                Detailed steps (from “top to down”): CRC removal, code block de-segmentation, channel decoding, rate matching and physical-layer hybrid-ARQ processing; bit-level descrambling; data demodulation; Inverse Discrete Fourier Transform (IDFT); antenna mapping and multi-antenna processing; OFDM processing, including Fast Fourier Transform (FFT) and CP removal; Analog-to-Digital conversion; power amplifier; and receiving from antenna.                                                
The described eNB functionality can be deployed in different ways. In one example, all the protocol layers and related functionality are deployed in the same physical node, including the antenna. One example of this is a pico or femto eNodeB. Another deployment example is a so called Main-Remote split. In this case, the eNodeB is divided into a Main Unit and a Remote Unit that are also called Digital Unit (DU) and Remote Radio Unit (RRU) respectively. The Main Unit or DU contains all the protocol layers, except the lower parts of the PHY layer that are instead placed in the Remote Unit or RRU. The split in the PHY-layer is at the time domain data level (IQ data, i.e. after/before IFFT/FFT and CP insertion/removal). The IQ data is forwarded from the Main Unit to the Remote Unit over a so called Common Public Radio Interface (CPRI)—which is a high speed, low latency data interface. The Remote Unit then performs the needed Digital-to-Analog conversion to create analog RF-data, power amplifies the analog RF-data and forwards the analog RF data to the antenna. In still another deployment option, the RRU and the antenna are co-located, creating a so called Antenna Integrated Radio (AIR).
Carrier Aggregation
The LTE Rel-10 specifications have been standardized, supporting Component Carrier (CC) bandwidths up to 20 MHz, which is the maximal LTE Rel-8 carrier bandwidth. An LTE Rel-10 operation wider than 20 MHz is possible and appear as a number of LTE CCs to an LTE Rel-10 terminal. The straightforward way to obtain bandwidths wider than 20 MHz is by means of Carrier Aggregation (CA). CA implies that an LTE Rel-10 terminal can receive multiple CCs, where the CCs have or at least have the possibility to have, the same structure as a Rel-8 carrier. CA is illustrated in FIG. 9. The Rel-10 standard support up to five aggregated CCs, where each CC is limited in the RF specifications to have one of six bandwidths, namely 6, 15, 25, 50, 75 or 100 RB corresponding to 1.4, 3, 5, 10, 15, and 20 MHz respectively. The number of aggregated CCs as well as the bandwidth of the individual CCs may be different for UL and DL. A symmetric configuration refers to the case where the number of CCs in DL and UL is the same whereas an asymmetric configuration refers to the case that the number of CCs is different in DL and UL. It is important to note that the number of CCs configured in the network may be different from the number of CCs seen by a terminal. A terminal may for example support more DL CCs than UL CCs, even though the network offers the same number of UL and DL CCs.
CCs are also referred to as cells or serving cells. More specifically, in an LTE network, the cells aggregated by a terminal are denoted primary Serving Cell (PCell), and secondary Serving Cell (SCell). The term serving cell comprises both PCell and one or more SCells. All UEs have one PCell. Which cell is a UE's PCell is terminal specific and is considered “more important”, i.e., vital control signaling and other important signaling is typically handled via the PCell. UL control signaling is always sent on a UE's PCell. The component carrier configured as the PCell is the primary CC whereas all other CCs are SCells. The UE can send and receive data both on the PCell and SCells. For control signaling such as scheduling commands this could either be configured to only be transmitted and received on the PCell. However, the commands are also valid for SCell, and the commands can be configured to be transmitted and received on both PCell and SCells. Regardless of the mode of operation, the UE will only need to read the broadcast channel in order to acquire system information parameters on the Primary Component Carrier (PCC). System information related to the Secondary Component Carrier(s) (SCC), may be provided to the UE in dedicated RRC messages. During initial access, an LTE Rel-10 terminal behaves similar to a LTE Rel-8 terminal. However, upon successful connection to the network, a Rel-10 terminal may—depending on its own capabilities and the network—be configured with additional serving cells in the UL and DL. Configuration is based on RRC. Due to the heavy signaling and rather slow speed of RRC signaling, it is envisioned that a terminal may be configured with multiple serving cells even though not all of them are currently used. In summary, LTE CA supports efficient use of multiple carriers, allowing data to be sent and received over all carriers. Cross-carrier scheduling is supported, avoiding the need for the UE to listen to all carrier-scheduling channels all the time. A solution relies on tight time synchronization between the carriers.
LTE Rel-12 Dual Connectivity
Dual connectivity is a solution currently being standardized by 3GPP to support UEs connecting to multiple carriers to send and receive data on multiple carriers at the same time. The following is an overview description of Dual Connectivity (DC) based on the 3GPP standard. E-UTRAN supports DC operation, whereby a UE with multiple receivers and transmitters, which is in RRC_CONNECTED mode, is configured to utilize radio resources provided by two distinct schedulers, located in two eNBs interconnected via a non-ideal backhaul over the X2. eNBs involved in DC for a certain UE may assume two different roles. An eNB may either act as a Master eNB (MeNB), or as a Secondary eNB (SeNB). In DC, a UE is connected to one MeNB and one SeNB. The radio protocol architecture that a particular bearer uses depends on how the bearer is setup. Three alternatives exist: Master Cell Group (MCG) bearer, Secondary Cell Group (SCG) bearer, and split bearer. Those three alternatives are depicted in FIG. 10. Signal Radio Bearers (SRBs) are always of the MCG bearer and therefore only use the radio resources provided by the MeNB. Note that DC can also be described as having at least one bearer configured to use radio resources provided by the SeNB.
Inter-eNB control plane signaling for DC is performed by means of X2 interface signaling. Control plane signaling towards the MME is performed by means of S1 interface signaling. There is only one S1-MME connection per UE between the MeNB and the MME. Each eNB should be able to handle UEs independently, i.e. provide the PCell to some UEs while providing SCell(s) for SCG to others. Each eNB involved in dual connectivity for a certain UE owns its radio resources and is primarily responsible for allocating radio resources of its cells. Coordination between MeNB and SeNB is performed by means of X2 interface signaling. FIG. 11 shows Control Plane (C-plane) connectivity of eNBs involved in dual connectivity for a certain UE. The MeNB is C-plane connected to the MME via S1-MME, the MeNB and the SeNB are interconnected via X2-C. FIG. 12 shows User Plane (U-plane) connectivity of eNBs involved in DC for a certain UE. U-plane connectivity depends on the bearer option configured. For MCG bearers, the MeNB is U-plane connected to the S-GW via S1-U, and the SeNB is not involved in the transport of user plane data. For split bearers, the MeNB is U-plane connected to the S-GW via S1-U and in addition, the MeNB and the SeNB are interconnected via X2-U. For SCG bearers, the SeNB is directly connected with the S-GW via S1-U.
Centralization of Radio Access Network (E-UTRAN) Functionality
Possible future evolution of the current Radio Access Network (RAN) architecture has been discussed. From a starting point in a macro site based topology, introduction of low power cells, an evolution of the transport network between different radio base station sites, a radio base station hardware evolution, and an increased need for processing power to give some examples, have given rise to new challenges and opportunities. Several strategies are proposed for the RAN architecture, pulling in sometimes different directions. Some strategies, like the gains of coordination, hardware pooling gains, energy saving gains and the evolution of the backhaul/fronthaul network, are working in favor of a more centralized deployment. At the same time, other strategies are working towards de-centralization, such as very low latency requirements for some 5G use cases, e.g., mission critical Machine Type Communication (MTC) applications. The terms fronthaul and backhaul are used in relation to the base station. The traditional definition for fronthaul is the CPRI based fiber link between the baseband Main Unit and the Remote Unit. The backhaul refers to the transport network used for S1/X2-interfaces.
The recent evolution in backhaul/fronthaul technologies has indeed opened up the possibility to centralize the baseband, often referred to as C-RAN. C-RAN is a term that can be interpreted in different ways. For some it means a “baseband hotel” like solutions in which the basebands from many sites are collocated to a central site, although there is no tight connection and fast exchange of data between the units. The most common interpretation of C-RAN is maybe “Centralized RAN” where there is at least some kind of coordination between the basebands. A potentially attractive solution is the smaller centralized RAN that is based on a macro base station and the lower power nodes covered by it. In such a configuration, a tight coordination between the macro and the low power nodes can often give considerable gains. The term “Coordinated RAN” is an often used interpretation of C-RAN that focuses on the coordination gains of the centralization. Other more futuristic interpretations of C-RAN include “cloud” based and “virtualized” RAN solutions where the radio network functionality is supported on generic hardware such as general purpose processors, and possibly as virtual machines.
A centralized deployment can be driven by one or several forces like, e.g., a possible ease of maintenance, upgrade and less need for sites, as well as harvesting of coordination gains. A common misconception is that there is a large pooling gain and a corresponding hardware saving to be done by the centralization. The pooling gain is large over the first number of pooled cells but then diminishes quickly. One key advantage of having the basebands from a larger number of sites co-located and interconnected is the tight coordination that it allows. Examples of these are UL Coordinated Multi-Point (CoMP), and a combining of several sectors and/or carriers into one cell. The gains of these features can sometimes be significant in relation to the gains of looser coordination schemes such as, e.g., enhanced inter-cell interference coordination (eICIC) that can be done over standard interfaces (X2) without co-location of the baseband.
An attractive C-RAN deployment from a coordination gain perspective is the C-RAN built around a larger macro site, normally with several frequency bands, and a number of lower power radios, covered by the macro site, that are tightly integrated into the macro over high-speed interconnect. The largest gains are expected to be seen in deployment scenarios such as for stadiums and malls. An important consideration for any C-RAN deployment is the transport over the fronthaul, i.e., the connection between the centralized baseband part and the radios, sometimes referred to as “the first mile”. The cost of the fronthaul, which vary rather greatly between markets, needs to be balanced against the benefits.
Problems
Ongoing discussions in the wireless industry in different for a seem to move towards a direction where the functional architecture of the 5G radio access network should be designed flexibly enough to be deployed in different hardware platforms and possibly in different sites in the network. In this way some benefits from centralization could be achieved such as: i) potential gains from coordination features (e.g. interference cancellation, CoMP); ii) more efficient usage of hardware resources; iii) potential energy savings by centralization of the baseband hardware; iv) possible ease of maintenance upgrade and less need for sites. On the other hand, it is recognized herein that there has not yet been proposed a solution to enable such a flexible functional architecture for 5G RAN.
The functional architectures of current RANs, such as the ones of LTE, Universal Mobile Telephony System (UMTS), and Global System for Mobile communication (GSM), have been mainly designed for specific deployment scenarios. Therefore the functional architectures are rather fixed. In LTE which has a rather distributed RAN, different functions of the protocol stack are assumed to have instances running in the same physical node, i.e. in the eNodeB, so that strong timing and synchronicity dependencies between these functions is not perceived as potential constraints for different deployments. Another reason for a rather fixed functional architecture in currently deployed RANs is that the RANs have been designed to provide services with similar requirements to a large extent. As one example, LTE was designed to support Mobile Broadband services with high data rates and lower latency compared to UMTS. However, it is also part of the current ambition for 5G RAN to address a much wider range of services such as Extreme Mobile broadband, Ultra-reliable, as well as mission critical and massive MTC. Under these new assumptions, scalability becomes a more complex challenge due to a wider variety of terminal or wireless device types generating a variety of quite different traffic and signaling types, and having different mobility assumptions in a heterogeneous environment.
It is also assumed that optimized designs will lead to a 5G RAN with multiple air interface variants. It is further recognized herein that the ambitious 5G requirements, the diversity of frequency bands and the advantages of interworking with legacy systems may require a tighter integration between the multiple 5G air interfaces and the legacy ones, beyond the interworking that exists today. Such tighter integration aims to extend multi-link integration concepts studied and standardized in 3GPP to the multiple air-interfaces such as DC. Thereby, completely new challenges may be envisioned assuming the specificities of each air interface, e.g. different frequency bands and time-frame structure. Also, integration features are typically designed to be specific to a Radio Access Technology (RAT). To give an example, the current CA and DC only provide “intra-LTE” functionality, i.e., functionality that can be used for example between different LTE carriers. Meanwhile, the existing multi-RAT features are not integration features, but rather interworking features designed for different levels, e.g., common subscription, and common core network, or features enabling some coordination via RAN inter-node interfaces for load balancing or coverage-based handover purposes.
It is thus recognized herein that the existing functional architectures of RANs are rather fixed, and that the current approaches to design them are not suitable to solve the scalability challenge inherent from the requirements that are to be addressed by 5G RAN.